本文目的：沒有甚麼目的，就是這 30 天心態上的紀錄。想到甚麼就寫甚麼，有點亂請見諒

本專欄編寫的環境

我這 31 篇文章皆是在 heptabase 中編寫，特點是一個 section 都可以化成一張卡片，並且很容易建立卡片間的關聯。它的優缺點如下：

缺點

• Notion 能使用的 markdown 格式更多一些

• Notion 支援超多種表格與顯示方式，在資料/時間管理方面的能力更強

• 好貴，最便宜的年付方案平均一個月也要 $ 270 (台幣)，若使用 AI 功能需要更高階方案或是自己申請 api 連接並買額度 (**好貴**應該是我的問題不是軟體定價問題)

優點

• 結合卡片盒筆記與視覺化展示的白板，可以清楚展示資料間的關係。例如下面是我在看深度學習原理時寫下的筆記，可以看到不同的卡片以視覺化方式清楚呈現彼此關聯 (這裡看更多範例)

  

• 容易看出資料之間的聯繫，例如可以看到下面這張卡片中有其他那些卡片跟它連線或引用它，並且可以直接連結到那些卡片

  

• 寫文章時可以同時顯示編輯中卡片、相關資料(先前寫過的卡片、相關網頁等)以及 AI 對話框。我在寫文時要使用 AI 時可以不用切換視窗非常方便

• 提供日誌功能，可以先在日誌中寫下草稿並在有空時整理

• 有在聽 podcast 的的話有內建的將 podcast 轉成逐字稿功能

我是看了這篇文之後開始使用 Heptabase。我使用 Heptabase 的原因是因為 Heptabase 比起 Notion 更適合用於學習。一次寫完整的筆記很困難，但若是寫像上面"卷積層“那樣的筆記就很簡單。我的習慣是在看書時簡單寫下像上面各式各樣的小卡片，在時間較多時將這些筆記放到白板上並尋找卡片間的功能並畫線

將卡片攤開、放置於白板上並畫姻緣線，這個過程中一定會思考關連並對建立自己對這個領域的架構。Heptabase 的白板非常適合這樣子視覺化的整理筆記方式，也因此在整理時對於整體架構就會有清楚的認知。

本專欄的寫作手法

我買了不少程式教學的書籍（很當然大部分都是翻翻、沒看完）。大部分的書本寫法都是 列出大功能 → 列出子功能 → 列出細部設定項 → 列出範例 ，尤其是在講解模組使用方式的書籍。我看這些書的目的就是在工作上遇到問題了，大概知道這個東西可能會用到。但是翻閱這些書時都覺得像國中時背誦成語唐詩(我常背到睡著)，好像知道了這些指令的存在，但是最重要的”如何根據工作需求、串連這些知識並 解決問題 可能是模模糊糊。

回想我在 MATLAB、VBA 到 Python 的程式學習過程中，我覺得在學習編寫程式做出完整成品的過程中，會遇到的的第一道牆是”將單獨的指令串成可達成目標的執行流程”。初學者不知道如何將心中或在 excel 中操作的"計算流程”，拆分成一個一個彼此串聯的最小步驟。但教學書的寫作方式只能讓我們知道單個小功能如何設定，如何實際設計腳本執行 資料讀取 → 資料清洗 → 計算 → 輸出 還是只能靠自己摸索。

若不知道如何拆解任務，就算直接叫 AI 編寫，也只會得到一坨很長、不知道怎麼改的程式碼，而且成品常"超乎想像”。但在自學者能得到的教學素材中，較少去提到"如何拆解實際問題”這個點。

因應上面的自學者大牆”不知道怎麼串接功能”，本專欄的寫作手法如下：

• 先定義我們製程/ 整合工程師可能碰到的情境，再去說明哪些模組可以解決這些問題

• 特別說明一個腳本 → 一個模組 → 多個模組串聯 → 一個完整專案是如何設計的，寫之前先知道到底要處理什麼

網路上寫得很好的語法教學文章很多、官方的 api 說明也大多清楚易讀(cv2例外)。因此本專欄更著重於”程式的架構是怎麼設計出來的”。我希望這系列文章可以讓過去主要依賴 Excel、但想要跨入 Python、R 等程式化資料分析的製程/ 整合工程師降低學習門檻 (這情境通常是資料量越來越大要整理不完了)。

本專欄編寫的動機

這篇鐵人賽的誕生與 AI 有強烈關聯，雖然我的內容上偏向自己設計程式。

我原本的工作內容是產品製程規劃、管理樣品交期、製程開發等項目(就是產品工程師啦)。但是因為我學生時接觸過數值分析，因此參與了新產品專案並開始使用 Python 腳本處理大量的數據。

(痾對我先接了任務後才學會 Python)

在編寫腳本的時候我實際遇到幾個問題：

• 不知道公開介面要怎麼設計，導致我不知道要怎麼把 UI 元件接上 method

• 每做一個新的分析，連"讀取檔案並清洗"這種重複的事都要一直重寫

• 腳本又臭又長，看得我頭昏眼花

• 換個輸出格式(例如6行變成7行)就要確認許多地方，像新開一個專案

• 找 bug 找好久才發現是 dict 的 key 打錯

• 族繁不及備載 ……

因為犯過的錯誤罄竹難書，因此我在今年 3 月某天下班時隨手點開 GPT 寫了個人背景與工作內容，並在最後問了一句”軟體工程師是怎麼設計程式的”。這個對話持續蠻久的、而且很長，如果用 A4 紙印出可以印出 215 頁，於是 AI 就成了我模組化開發的家教。

AI 如何幫助自學者

我跟 AI 這樣對話之後並照做與討論之後，寫程式的思考方式和年初有很大的不同。我現在編寫程式時會花蠻大心力在「如何讓程式碼更容易重複使用與修改」，而不是會動就好。

我認為 AI 在我們這種跨領域的學習者來說，最大的好處 AI 會提點我們認知以外的「其他領域的知識」，而這些東西很可能我們根本不知道要去學習。

我之前想自己寫 GUI 程式時便有買相關書籍並在裡面看到「UI 與 main」要分開這種描述，但沒有清楚的寫到職責分離與 MVC （也可能是我當時根本看不懂）。我是在與 AI 討論「如何像一個軟體工程師？」的過程中才知道有 MVC 架構這種寫法。

若我是沿著工作內容演變、與自己的認知設計學習地圖，很可能不知道要去了解模組化程式設計。我會一路資料分析工作下來、可能知道更多數據或圖像分析的方法，但還是被各種長又複雜的腳本困擾著。

專欄的編寫心得

寫個在網路上會有人看的文章一直是我的夢想之一，最早是想要記錄我心愛的塊根仙人掌生長紀錄，但是我懶一直都沒有動手。而本專欄是今年我寫出覺得滿意的 GUI 程式後，一時起意就想要參加。我當時對此專欄的設定有三個，主要是以下三方面都不常見：

• 寫一個讓自學者可以學會程式架構的教學

• 寫一個跟 wafer 分析相關的教學

• 不要只講模組怎麼使用，而是要在實際會用到的框架下，盡可能的說明模組的架構設計 (太底層的我也不懂)

針對半導體業界常見之 wafer mapping，kaggle 上有 mapping 資料集可以玩玩看

我覺得寫鐵人賽的好處是我更清楚我使用的模組架構，不少東西是我在編寫期間因應”想說明的更清楚”而去查的，還可以作為筆記讓我隨時查閱。壞處是我今年 8~10 月的空閒時間幾乎都砸在這些文章上了(也是因為我編寫期間會東摸摸西摸摸)。

這是我心愛的龜甲兜，2023年購入時 4 cm 大，現在已經 10 cm 了頭好壯壯

AI 在寫文章時扮演的腳色

我從 5 月初開始寫這些文章，到 9/14 實際開賽時累計 19 篇 (原本預計要有23篇)，我編寫的方式演變如下：

1. 純手動編寫 code 後並確認可執行後，自行設計與編寫文章內容 (day 3~ day 8)

2. 使用 AI 生成 code，並自行設計與編寫文章內容 (day 14~ day 16)

3. 使用 AI 生成 code 並討論文章內容，例如我會提出分段方式、標題、各段預計內容；AI 補充或建議編寫方向，並將條列式大綱生成於 card 後我自行編寫文章內容 (day 17~ day 26)

4. 使用 AI 生成 code 並討論文章內容，也會提出分段方式等文章架構，但讓 AI 讀取我先前文章並學習用字遣詞後生成新文章，然後我重新修改與編排內容 (day 27~ day 29)

可以從上面的流程發現 AI 介入的比例越來越高，原因是因為方式 1 真的太花時間，一周就算把可用時間都空出來也只能寫一篇，並且我在近期工作中開始嘗試由 AI 生成 code 而不是我自己寫。

我覺得最好的編寫方式是方式 3 ，因為我自己花最多心思的地方就是在方式 3 的 section 。這裡牽涉到本系列重點"架構設計”，因此這幾篇的篇幅都很長，這個時候可以使用 AI 協助統整想法與生成大綱就節省我很多時間。我也最滿意方式 3 的編寫效果，有達到我當初的設定的 3 個目標。

方式 4 的部分是因為看到網路上關於口述後讓 AI 整理成文稿的的教學，且快要開天窗了(這才是重點)，因此嘗試讓 AI 生成本文後我再進行編排與修改。就算給 AI 讀取我先前寫的文章且有討論過，AI 生成之內容還是跟我的寫法與文風有差異，例如 AI 的分段數很多、偏好用 quote 等。而且若寫文章也是作為學習筆記使用，方式 4 會降低對該主題的印象。

因此 AI 可以是一個隨 call 隨到、記憶力好的好編輯，但不會也不該是一個好作者。

結語

這一篇文主要說明我的動機與編寫方式，感謝你看到這裡。明年鐵人賽再見面。